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ABSTRACT 


This final technical report describes the objectives, plans and accomplishments of the NASA 
Johnson Space Center sponsored program entitled “Automated Subsystems Control for Life 
Support System (ASCLSS), NAS9- 16895.” The program objectives were to define a generic 
automation approach for Space Station subsystems and to demonstrate the selected auto- 
mation technique by controlling and monitoring the Air Revitalization Group (ARG) of a 
regenerative Environmental Control and Life Support System (ECLSS). The ARG consists 
of three ECLSS processes: O 2 generation, CO 2 concentration, and CO 2 reduction. 

The ASCLSS automation approach developed by Honeywell and Life Systems Inc. consisted 
of a hierarchy of distributed controllers implemented with 1750A microprocessors and a high 
speed busing network. System level, local process control, and real-time operating system 
software were developed and integrated with the controller hardware to demonstrate the 
automated control and monitoring of the three Space Station ECLSS processes. The ARG 
processes were simulated by three ARG simulators, implemented in individual personal 
computers. A crew man-machine interface (MMI) was included in the automation system to 
develop and demonstrate the control authority allocated between the crew, the upper level 
system controller, and the lower level ARG process controllers. 

The completed ASCLSS system has successfully demonstrated many important features that 
are currently being considered for Space Station automation and control. These important 
features emphasized commonality of hardware and software, implementation of standards, 
incorporation of a high level of system autonomy, and the placement of the crew operator in 
a role of supervisory control. 
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Section 1 


INTRODUCTION 


Early in 1983, NASA initiated a technology development program entitled, “Automated 
Subsystem Control for Life Support System” (ASCLSS, NAS 9-16895). The national com- 
mitment for a manned Space Station was evolving and NAS recognized that a permanent 
presence of man-in-space would require highly automated systems. The ASCLSS program 
was funded by the NASA Office of Aeronautics and Space Technology and the Crew and 
Thermal Systems Division of NASA Johnson Space Center. 

The ASCLSS program primary objectives were to define and develop a generic approach to 
automation and control of Space Station systems and to demonstrate the selected automation 
approach by controlling and monitoring the Air Revitalization Group (ARG) of a represent- 
ative Space Station regenerative Environmental Control and Life Support System (ECLSS). 
The autonomous operation of the ECLSS Air Revitalization Group is considered one of the 
most important requirements for an ultimately successful Space Station operation. An ad- 
ditional ASCLSS program objective was to demonstrate the importance of subsystem sim- 
ulators for the development, demonstration and verification of the generic automation and 
controls approach. 

The contract, which was initiated in May 1983, was managed by Honeywell Space and 
Strategic Avionics Division (SSAvD Clearwater, FL), with participation and important con- 
tributions by Life Systems, Inc. (Cleveland, OH), and Honeywell Systems and Research 
Center (Minneapolis, MN). The ASCLSS program team roles and technical responsibilities 
are summarized in Table 1-1. The program represented a blend of Honeywell’s extensive 
automation and controls experience in commercial, industrial, and manned space applications 
with the environmental control and life support systems technology and experience of Life 
Systems, Inc. 

The overall program task plan and schedule shown m Figure 1-1 followed a logical sequence 
of development steps starting with an extensive applications study during the first year of 
the program. The applications study evaluated and assessed the automation and control 
(A&C) requirements for the Space Station DMS, GN&C, ECLSS, and electric power (EPS) 
subsystems. Based on these requirements, a generic approach to Space Station A&C was 
defined. The approach featured a hierarchical and distributed controller architecture with a 
man-machine interface for crew supervisory control and individual simulators for each ARG 
process. Following design and fabrication of the automation system hardware and software, 
the major elements were individually tested prior to system integration. Final integration 
of the ASCLSS demonstration system took place at Honeywell SSAvD with delivery and 
system acceptance test at NASA JSC on 28 July 1986. Subsequently, a small add-on devel- 
opment program was conducted to develop enhanced demonstration features of the system. 
Final delivery of the ASCLSS system to NASA JSC occurred on 7 April 1987. 

The remainder of this report summarizes the major objectives and significant results of the 
ASCLSS program tasks. Section 7 identifies the important “lessons learned” for the devel- 
opment program and Section 8 provides recommendations for additional areas of investigation 
and study. More detailed program information and technical data may be obtained from the 
documentation and references listed in Appendix A. 
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Table 1-1. NASA JSC ASCLSS Program Responsibilities 


Honeywell SSAvD 

• Program Lead and Management 

• Automation Systems Engineering 

• Automation and Control Hardware Development 

• Generic, Distributed, Layered Operational Software Development 

• System Integration, Test and Demonstration 

Life Systems Inc. 

• ECLSS System Engineering 

• ARG System and Process Application Software Development 

• ARG Simulators/Simulations Hardware and Software Development 

• ARG Application/Simulation Software Test and Integration Support 

Honeywell SRC 

• Applications Study Lead 

• Human Factors/Crew Operator Interface Development 

• Automation- System Man-Machine Interface (MMI) Hardware/Software Development 

• MMI System Test and Integration Support 



• INTEGRATED SENSORS 

• MAN/MACHINE INTERFACE 

• MAINTENANCE AND REPAIR DOCTRINE 

• INTERMODULE COMMUNICATION 

• DATA MANAGEMENT SYSTEM INTERFACE 

• GENERIC CONTROLLER STANDARDIZATION 

• VALUE OF AI-EXPERT SYSTEMS 


Figure 1-1 . ASCLSS Task Plan and Schedule 
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and this acknowledgment identifies their significant commitments and achievements: 
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Frank H. Samonski, Jr. 

Nick Lance, Jr. 
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• Honeywell Space and Strategic Avionics Division (Clearwater, Florida) 

Dr. Roger F. Block Warren Jokinen 
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Section 2 


APPLICATIONS STUDY (Task 3.1.1) 


2.1 TASK OBJECTIVES 

The primary objective of the ASCLSS application study was to evaluate the feasibility and 
advantages/disadvantages of implementing a generic “automation technique” for several 
Space Station systems. The Electric Power System (EPS), Environment Control and Life 
Support System (ECLSS), and the Guidance, Navigation, and Control (GN&C) system were 
to be evaluated. Divisions of automation and control (A&C) responsibilities between the 
operator/crew, the system level control, and subsystem level of control were to be defined 
and partitioned. These A&C responsibilities were to consider automated command and con- 
trol, subsystem and system performance monitoring, fault detection and isolation, fault tol- 
erance, performance trend analysis, incipient failure detection, redundancy management, 
and onboard maintenance operations. 

After defining the automation requirements including controller architecture, processing 
throughput, memory, power, and word sizes across the Space Station systems, a generic 
automation approach was to be defined to meet the system needs and achieve, as well, the 
significant benefits of commonality of hardware and software. 

Also, a conceptual design for the Space Station ECLSS automation and control was to be 
defined based on the selected, generic automation technique. And, finally, a technology as- 
sessment was to be conducted to evaluate the availability and/or development required to 
implement the generic automation and control approach on the Space Station at initial 
operational capability (IOC). 


2.2 TASK APPROACH 

Space Station A&C requirements were synthesized from NASA sponsored Phase A Space 
Station studies and on-going system studies at Honeywell, Life Systems, Inc., and Rockwell 
(a subcontractor for the applications study). These requirements established an overall ge- 
neric controls architecture and the functional partitioning for A&C responsibility for the 
ground support, the on-orbit crew, the Data Management System (DMS) man-machine in- 
terface, and the hierarchy of system automation and control elements. 

The generic A&C approach was evaluated against three major Space Station systems (ECLSS, 
EPS, and GN&C) which were considered representative of the full spectrum of applications 
across the Station. This evaluation tested the viability of the generic A&C approach having 
broad applicability. And, finally, an assessment was conducted to evaluate the available 
technology required to meet the generic A&C requirements and to identify any required new 
developments. 
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2.3 APPLICATION STUDY RESULTS 


2.3.1 Requirements 

After an extensive review of NASA reports, Space Station Phase A studies, and on-going 
system studies, the following general requirements were selected to drive the development 
of the generic automation and control approach for Space Station: 

• Modular Space Station architecture with accommodation for incremental buildup. 

• Technology readiness for the automation approach based on 1986 design start for core 
modules and 1992 design start for added (evolutionary) modules. 

• Maximum practical autonomy from the ground (reduce costs of ground facilities and 
personnel). 

• Maximum automation of routine subsystem operations to minimize crew workload and 
free them up to conduct system user activities. 

• Strong emphasis on commonality of hardware and software. 

• Twenty years on-orbit operational life achieved through on-orbit maintenance. 

• Flexible for growth in performance and technology insertion. 

2.3.2 Automation and Control Architecture 

These requirements led to the definition of a basic automation and control architecture for 
Space Station systems shown in Figure 2-1. The architecture features a module controller 
which interfaces to the Space Station Data Management System (DMS) high speed com- 
munications network via a Network Interface Unit (NIU). A module level man-machine 
interface (MMI) or work station also interfaces to the module controller. All critical Space 
Station system controllers (ECLSS, GN&C, EPS, etc.) that reside in that specific module 
interface to the module controller via an intra-module bus. 

Any given system controller like the GN&C or ECLSS, may have several basic controllers 
at the lowest level of the control hierarchy. The basic or process level controllers perform 
the critical control functions for a given process (e.g., the CO 2 concentrator for the air re- 
vitalization group (ARG) of the ECLSS or the inertial measurement unit for the GN&C). 
This automation architecture accommodates a high level of autonomy and allows for a de- 
scending hierarchy of control authority functions which are partitioned as shown in Figure 
2-1. This module-based, three-level hierarchy of distributed controllers provides for generic 
commonality, efficient communications, localized processing and control, and accommodation 
for fail-safe, redundant operation. Under this architecture, the Space Station DMS may be 
viewed as a system level manager of the complete Station-level data base and a global 
communications network between modules and the major Space Station systems and space 
operations segments. 

2.3.3 Generic Controller Concept 

Having defined a basic automation and control architecture, the following additional re- 
quirements were defined for the generic controllers making up the architecture: 

• Emphasize commonality of hardware and software. 

• Minimize cost of design, development, test, integration, maintenance, and ownership. 

• Provide for growth and technology insertion. 

• Emphasize implementation of standards. 
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REQUIREMENTS 
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SUBSYSTEM 

CONTROLLER 

MIL-STD-1 750A 
PROCESSOR 
MEMORY BASIC 
MEMORY EXPANSION 
MIL-STD-1 553B BUS 
INTERFACE 
POWER SUPPLY 
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BASIC CONTROLLER 

• MIL-STD-1 750A 
PROCESSOR 

• MEMORY BASIC 

• MIL-STD-1 553B BUS 
INTERFACE 

• DIGITAL I/O 

• ANALOG INPUT 

• ANALOG OUTPUT 

• PULSE RATE/FREQ. 
CONVERTER 

• SENSOR BUS INTERFACE 

• SPECIAL I/O 

• POWER SUPPLY 

• CHASSIS 


Figure 2-1. Requirements and Building Blocks for a Generic Controller 
Applied Anywhere in the A&C Architecture 


A single controller could not fulfill all these requirements at every level of the architecture 
without penalties in size, weight, power, and cost. However, a family of controllers assembled 
from standard card level elements could come very close to meeting the requirements with 
minimum penalties. 

The Honeywell generic controller concept is shown in Figure 2-2. The three basic controller 
functions consisting of a computer function (CPU/memory), a communications function (serial 
data/command buses), and input/output functions (analog/digital signals and commands) can 
all be implemented in card level ORUs and several standard chasses capable of meeting the 
controller requirements at each level of the automation hierarchy shown in Figure 2-1. This 
selected generic A&C approach is similar to the current Space Station concepts featuring 
common DMS elements (SDP, EDP, MDM, NIU) populating a hierarchal and distributed 
controls architecture in all systems. 

The baseline A&C architecture and generic controller concept was then applied to the specific 
requirements of the ECLSS, GN&C, and EPS systems in order to verify the approach. Out 
of this detailed analysis and study emerged the family of controllers and the data bus rec- 
ommendations shown in Tables 2-1 and 2-2, respectively. The card level building blocks for 
the controllers would have the performance characteristics listed in Table 2-3. 

Two additional important results of the ASCLSS applications study were the Space Station 
automation system technology assessment summarized in Table 2-4 and a set of design 
doctrines for the Station Level work station or man-machine interface listed in Table 2-5. 
Many more details from the applications study may be reviewed in references 1, 2, and 3 in 
Appendix A. 
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Card Elements Selection Tailored To System Requirements 



Card Level Functions 


MIL-STD-1750A PROCESSOR 
MEMORY BASIC 
MEMORY EXPANSION 
ANALOG INPUT 
ANALOG OUTPUT 
DIGITAL I/O 
MIL-STD 1553B BUS 
PULSE/FREQUENCY CONVERTER 
SENSOR BUS INTERFACE 
SPECIAL I/O 
POWER SUPPLY 
CHASSIS (2 SIZES) 


CONTROLLERS HAVE THREE 
BASIC FUNCTIONS: 

• COMPUTER 

• COMMUNICATION 

• INPUT/OUTPUT 


STANDARD 

• PACKAGING 

• COOLING 

• CONNECTORS 


STANDARDIZING COMMON FUNCTIONAL ELEMENTS 
RESULTS IN A FAMILY OF GENERIC BUILDING BLOCK 
ELEMENTS THAT CAN BE SELECTED TO MEET SYSTEM 
CONTROL REQUIREMENTS 


Figure 2-2 . Honeywell Generic Controller Concept 


Table 2-1. Worst-Case Requirements for 
Basic Controller and Interconnect 



ECLSS 

EPS 

G&NC 

CPU 

185 KIPS 

50 KIPS 

240 KIPS 

ROM (16-Bit Words) 

32K 

40K 

32K 

RAM (16-Bit Words) 

32K 

16K 

32K 

Mass Storage^ (16- 
Bit Words) 

92K 

0 

258.2K 

Bandwidth 

64K bps 

400K bps 

50K bps 


(1) Assumes one day of storage. No trend analysis in EPS basic 
controller, thus no storage. 
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Table 2-2 . Bus Requirements and Recommendations 



Basic 

System 

Module 

Media 

Twisted Pair 

Coax 

Fiber Optics 

Type 

Serial 

Serial 

Serial 

Data Rate 

1 MBPS 

10 MBPS 

10-500 MBPS 

Access Method 

Single Bus 
Controller 

Single Bus 
Controller 

Distributed Bus 
Control 

Delay* 

58 Millisec Worst Case Transport Delay 


* Worst Case for Shuttle On-Orbit Operation 


Table 2-3. Controller Family Performance and Capacity Recommendations 



Family 

CPU 

(16 

Bits) 

RAM 

(X16) 

EPROM 

(X16) 

Mass 

Storage 

(X16) 

Number 

of 

Dumb 

Number 

of 

Dumb 

Size (3) 

Weight (3) 

Power 

Family 

Member 

MIPS 

K 

K U) 

(M 2 ) 

Sensors 

Actuators 

(In 3 ) 

(lbs) 

(Watts) 

Module 

A 

2 

80 

336 

400 

0 

0 

tbd (4) 

TBD 

TBD 

Controller 

System 

A 

2 

80 

336 

10 

0 

0 

TBD 

TBD 

TBD 

Controller 


B 

1 

80 

96 

1 

0 

0 

TBD 

TBD 

TBD 

Basic 

A 

1 

80 

96 

0 

72 

10 

300 

11 

44 

Controller 


B 

1 

80 

96 

0 

8 

2 

140 

4 

21 


C 

1 

16 

32 

0 

72 

10 

250 

10 

40 


D 

1 

16 

32 

0 

8 

2 

100 

3 

17 


(1) Assumes most controller functions executed from EPROM 

(2) Module controller data base includes maintenance procedures and logistics data 

System controller data base includes data structures for all control points in the controller's domain 

(3) Size and weight include card cage, enclosure and power supply but not cooling. All values are based on 
current technology 

(4) Depends on type of mass memory selected. 
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Table 2-4 . Controller Technology Assessment 


Technology Element Recommendation 


Rationale 


A. Instruction Set Architecture MIL-STD-1750A (16 bit word) 


Capitalize on availability of 
development tools, multiple hardware 
implementations, vast user base, 
facilitates portability of software 


B. CPU Throughput 

C. Semiconductor logic 
circuitry for I/O and bus 
interfaces 

D. Semiconductor Memory 


E. Bus Interfaces 

F. A/D and D/A conversion 

G. Integrated Sensors 


H. Chassis/Power Supplies 


I. Software Higher Order 
Language 


1 mip CMOS, dais mix, single 
chip 

Bipolar at 0.5 ns gate delay 
CMOS at 5 ns gate delay 

CMOS static RAM (64K to 256K, 
50 mw, 75 ns access) 

CMOS EPROM (64K to 256K, 50 
mw, 150 ns access) 


On silicon sensors with associated 

microprocessor/memory/bus 

interface 

Standard size packages with 
mother/daughterboards and 80 
percent efficient switching 
regulators 

• ADA (MIL-STD-1815A) 

• Closest relative to ADA is 
Pascal 


Low power dissipation at sufficient 
speed 


Low power with sufficient density and 
access time 


Well known standard used in many 
control applications 


• Not available until later 1980’s 

• Offers control, size, weight, and 
cost advantages 

Modular packaging that 
accommodates on-orbit maintenance 
at the card level 

All future DoD and NASA flight 
software will require ADA. Space 
Station will select the ADA language 


Available 


MIL-STD-1553B (1 MBPS) 

12 to 16 bit, ±10Vdc, 1 Available 

microsecond per bit 


Table 2-5. Human! Machine Interface Doctrine 

• Minimize crew workload for routine operations 

- Infrequent maintenance intervals (month or longer) 

- Maintenance tasks <1/2 hour 

- Subsystems automatic startup, shutdown, mode changes 

- Automatic fault detection, reconfiguration 

- Trend data automatically stored and interpreted 

• Scheduled maintenance no sooner than 8 hours 

• Display system designed to be user friendly 

- Menu driven data/displays 

- Built-in/integrated diagnostic capability 

• Crew maintained in supervisory control 

- Caution, warning, alarms provided with explanatory procedures 

- Continuous system status provided at all times. 
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Section 3 


DESIGN (TASK 3.1.2) 


3.1 TASK OBJECTIVE 

Based on the selected generic automation approach, a design for the automation and control 
of the air revitalization group (ARG) in the ECLSS system would be developed. The design 
would partition the functional requirements for performance monitoring and control, fault 
detection/isolation, trend analysis, and include various aspects of redundancy management 
and maintenance provisions. 

As part of the preliminary design, differences in hardware and software implementation from 
the generic A&C technique defined for the Space Station in the application study (Task 3.1.1) 
and the proposed automation approach to be developed and demonstrated would be explained. 
The final design process was to include design requirements and specifications and software 
• flow charts. Special emphasis was to be directed at defining and designing subsystem process 
simulators capable of checking out, testing, and demonstrating the generic automation tech- 
nique to be developed on the ASCLSS program. 


3.2 TASK APPROACH 

Significant design tradeoffs were conducted to select the ASCLSS baseline automation design 
to be demonstrated. Concepts ranged from available commercial microprocessors, Life Sys- 
tems, Inc. process controllers, to Mil-Standard control elements. Final design selection em- 
phasized strong commonality of hardware and software, military standards, and real-time 
control features that are being considered in the Space Station DMS. The ASCLSS program 
goal was to implement the automation and control approach with high fidelity to Space 
Station so as to develop the most relevant lessons learned. 


3.3 TASK RESULTS 
3.3.1 Hardware System 

The baseline ASCLSS demonstrator configuration is shown in Figures 3-1 and 3-2. The 
configuration consists of three basic (subsystem) controllers that provide the automation and 
control function for the three processes making up the air revitalization group (ARG) of the 
regenerative ECLSS subsystem. The ARG processes include: 

• The C>2 generation process (static feed electrolyzer [SFE]). 

• The CO2 concentrator process (electrochemical depolarized concentrator [EDC]). 

• The CC>2 reduction process (Sabatier CO2 reduction subsystem [S-CRS]). 
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Figure 3-1 . ASCLSS Demonstration System 
for ARG Automation and Control 


RS232/422 



SCRS 

SIMULATOR 


BASIC 

CONTROLLER 

3 

C0 2 REDUC (SCRS) 

» COMMON, CARD LEVEL 
HARDWARE ELEMENTS 
1750A CPU, 

64K ROM, 

MIL-STD* 15538 CMND RESP 
OUAL RED BUS 
HIGHSPEED SERIAL 
BUSSES (230 KBAUD) 
INDIVIDUAL PROCESS 
SIMULATORS 


EDO 

SIMULATOR 


Figure 3-2. ASCLSS Automation and Control Demonstration System 
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The three basic controllers communicate to an ARG system controller via a dual redundant 
MIL-STD-1553B busing network. In the ASCLSS demonstration system, the ARG process 
hardware is represented by three real-time simulators implemented by personal computers. 
A man-machine interface (MMI) communicates with the system controller via an RS232/ 
RS422 serial bus. The MMI provides for ASCLSS automation system and ARG performance 
monitoring by the operator and provides for crew operational command authority. 

Some of the more important features of this hierarchal and distributed automation system 
are shown in Figure 3-3 and listed below: 

• All controllers at each level in the automation hierarchy are constructed from exactly 
the same building blocks or cards. All controllers feature the same, single board MIL- 
STD-1750A central processing unit (CPU) implemented with a Fairchild F9450 single 
chip microprocessor (750 KIPS). Selection of the MIL-STD-1750A microprocessor was 
based on its effective, functional architecture for high speed control processing and the 
availability and maturity of the software development tools, programming environ- 
ments, and hardware. Figure 3-4 provides a photograph of the generic controller hard- 
ware and the associated 1750A CPU card. 
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Figure 3-4. 17 50 A Microprocessor and CPU Card 


• The memory cards in each comp”* ^/controller are the same (64K words E^PROM, 40K 
words RAM). Where additional memory capacity is required, 8K words of memory can 
be easily added or additional memory cards of the same type can be added onto the CPU 
computer bus. The 1750A CPU can address up to 1 million words each of data and 
instruction memory. 

• Bus interface cards are the same in each computer/controller where it interfaces to a 
specific communications bus (RS232/RS422 or 1553B). Bus protocol differences (i.e., 
“master” or “slave”) are implemented in operating system software packages. The MIL- 
STD-1553B bus was selected because it is a high speed, standard bus that meets the 
demonstrator intercommunication requirements (1 MBPS). 

• Although not implemented in ASCLSS, the input/output (I/O) or signal conditioning 
circuits required for a given process (i.e., EDC, S-CRS, or SFE) can be designed and/or 
implemented from standard/available electronic cards (e.g., signal amplification, Analog 
to Digital (A/D) and Digital to Analog (D/A) conversion cards). 

• Note, in Figure 3-2 the ASCLSS demonstrator system also includes personal computers 
(PC) employed as ARG process simulators and as an MMI. The significance of simulators 
to the automation and control development cycle is discussed in Section 3.3.3 of this 
report. The high speed (230 KB) RS232/422 serial bus linking the PC simulators to the 
basic controllers was necessary to achieve real-time control performance from the sim- 
ulations and controller interfaces. 
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The ASCLSS automation system was designed to demonstrate several important benefits 
that can be achieved through a common approach to automation across all Space Station 
systems: 

• The generic design and implementation in common hardware and standard software 
allow automation techniques to be developed and validated to a high degree and then 
applied uniformly to specific applications across all of the Space Station systems. 

- Each subsystem or process vendor or component supplier does not have to concep- 
tualize, implement, and validate his own automation approach. 

- All parties to the Space Station (NASA, subcontractors, crew) will develop and have 
a better understanding of all Space Station systems (important to system upgrades/ 
evolution over the operational lifetime and to rotating crew and program personnel 
throughout the Space Station life cycle). 

- The many contractors and the large personnel base working with the generic au- 
tomation concept and its implementation will provide a high degree of refinement, 
a broad integration and test base, and a greater assurance of hardware and software 
verification prior to Space Station initial operational capability (IOC). 

• The generic automation approach allows a more universal approach to subsystem and 
system redundancy management (RM). Redundancy management requirements can be 
studied “across-the-board” and generic approaches and techniques devised to fit specific 
categories for system requirements (i.e., triple redundant, dual-dual, active standby, 
controller cross-strapping, etc.). 

• The generic automation approach provides incentive for and accommodates the imple- 
mentation of common and standard controls hardware and software (important for on- 
orbit maintenance requirements). 

• The real-time automation and control hardware can be divided into three general cat- 
egories: 

- Computer functions 

- Communications functions 

- Signal conditioning functions. 

Within each functional category, a library of standard electronic cards can be designed 
so each subsystem or process vendor selects from the standard cards to meet his particular 
controller requirements. Process or component controls can be designed and built from 
a standard set, or library, of generic controller electronic cards, chasses or packages, 
and power supplies. Each vendor selects from the generic equipment to build a controller 
for his specific process, component or subsystem. 

Thus, commonality and implementation of standard or generic hardware and software dem- 
onstrated in ASCLSS appears to offer significant benefits in lower development and life cycle 
costs for Space Station automation and control. The ASCLSS approach also strongly supports 
the requirements for on-orbit maintenance, repair, and sparing (i.e., in this case the orbital 
replaceable unit [ORU] is at the electronic card level). Greatly simplified ground test checkout 
and hardware/software verification should also be realized eliminating the need for an ex- 
tensive Station Avionics Integration Laboratory (SAIL) effort. 
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Many of these hardware features and their associated benefits are being considered in the 
current Space Station DMS and distributed control system designs throughout the Station. 

3.3.2 Software System 

The same benefits associated with commonality of hardware control elements are also achiev- 
able by providing a generic automation system with a significant content of common or 
generic software elements. This concept is currently being promoted in the present Space 
Station DMS architecture in the form of the distributed operating system (DOS). In the 
ASCLSS program, Honeywell developed a challenging layered software approach which fa- 
cilitates independent verification and validation of application and operating system soft- 
ware. 


Figure 3-5 illustrates the ASCLSS layered software approach employed in each of the four 
controllers. The approach has the following features: 

• Each sublayer is transparent in functionality to the process control application software. 

• Systems control and operating system software which are common in each controller 
require no repeated validation (developed and verified - once!). 

• The controller I/O is performed by generic hardware and software modules. 

• The native processor or target hardware (1750 A) is not a development concern for the 
application supplier or process vendor (LSI in this case). The application software strictly 
deals with an I/O data base software architecture. 
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Figure 3-5., Generic Controller Layered Software Approach 
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• Process control application software development can take place with existing HOL tools 
at the process vendor’s facility. 

• Much of the automation/control operating system software is written directly in 1750A 
assembly language for reasons of computing speed and the fact that some lower level 
instructions cannot be implemented by an HOL statement. 

• Only one software interface needs to be debugged at the integration phase (the I/O data 
base). 

The ASCLSS program stressed software commonality and modularity. The ASCLSS layered 
software architecture shown in Figure 3-6 is divided into four layers: 

• The operating system is common to all controllers. It is written in 1750 A assembly 
language and performs all network and I/O data transfers as well as task scheduling. 

• The system control software acts as the agent for the application software, with its I/O 
data base, and the operating system. Due to protocol features, there are some minor 
differences between the system control for the system controller and the subsystem basic 
controllers; the system control software in the three basic controllers are identical. The 
system control layer is written completely in Pascal. 

• The I/O data base is unique to each controller. It is created through data declaration 
constructs and is used for transparently transferring data between controllers on the 
data bus and from/to sensors/effectors. The format/constructs for the I/O data base are 
the same in each controller, however the data is unique to the application. 

• The process control (and process management) application software layer is the process 
application software which is unique to each application. This layer is written entirely 
in Pascal. 

The ASCLSS application software and much of the system control software is written in 
Par.ca l. The ASCLSS software design and the selection of the Pascal language provide an 
easy path for future upgrading to ADA. 

Honeywell addressed the ASCLSS baseline approach by defining a set of generic hardware 
and software elements that would be delivered to a subsystem and/or system developer that 
would address the problems of common hardware and software for a wide diversity of ap- 
plications. 

For a subsystem and/or system developer, the highest risk occurs at integration time. If 
system and subsystem requirements have been poorly defined or not implemented correctly, 
serious integration problems arise and often ripple into the design of the entire system. Most 
of these problems manifest themselves when the efforts shift from testing in a development 
environment to testing in the target environment. This is due mostly to operating a different 
hardware environment for the software development effort and then shifting from non-real- 
time to real-time events in the target hardware. 

Development tools often become more primitive in the target environment and multiple 
events need to be examined at the same moment in time. An added problem is that application 
software tends to be very non-deterministic in execution, especially software which monitors 
and controls a subsystem. When a generic set of hardware and software are to be developed 
for application developers, all of these issues must be addressed. 
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Figure 3-6. Layered Software Architecture Established 
Software Commonality 


The automation and control of the ARG is typical of most systems which are comprised of 
distributed control elements. Generally these subsystem elements must be autonomous but 
they each affect each other through their roles in the ARG as a system. Therefore an overall 
supervisory monitor and control hierarchy for monitor and control is required. Each sub- 
system control element provides for autonomous control of the subsystem. All subsystem 
controllers communicate with a system level controller but not with each other, therefore a 
strict hierarchy is established. For ASCLSS, the MMI performs as the higher level control 
authority for the system controller, but in larger systems this control could be a module level 
controller or the operations management system (OMS) on the Space Station. The system 
controller can perform its functions autonomously without the MMI or the higher level control 
authority. 

If the layered software architecture were not implemented, each Space Station application 
software developer would have to address the following major design issues: 

1. Operating System Interface 

2. I/O to sensors and actuators 

3. Communications interfaces and protocols 

4. Timing and Synchronization 

5. Tasking Knowledge 


3-8 



6. Location of data in a multiple controller set 

7. Delivering commands and data in a distributed controller set. 

Honeywell addressed these design issues as a generic problem in order to implement its 
baseline common software approach. In ASCLSS, the application software developer (Life 
Systems, Inc) developed application and test software on an IBM PC which was targeted for 
a controller with 1750A instruction set, different system architecture, different operating 
system, different communications interfaces, and different execution speed. 

The Honeywell layered software approach allowed the application software developer to 
develop software as a collection of finite state machines independent of the design issues 
described above. The finite state machine concept is an approach to decomposing a large, 
complex software task (i.e., the application control software for the ARG system) into easy- 
to-code modules and state- tables. The resulting software avoids convoluted code dependent 
on many different input conditions and facilitates test and verification of each clearly defined 
software module. Thus, the application software in each ASCLSS controller consists of a 
multitude of modules each responsible for a task or operation which it performs based on 
the state it’s in and the current values of specific input parameters. 

A table driven software layer defined as “System Control” software was developed which 
presented a total data interface to the application software in each controller. System Control 
software provides for synchronous and asynchronous communications between the system 
controller and subsystem controllers via symbolic data structures whose content is defined 
by the application software . The I/O to sensors and actuators is performed in the same manner . 
By using data structures as the only interface to the application software, the application 
software can be developed and tested on any development system since memory is handled 
the same on any computer from a High Order Language (HOL). These data structures col- 
lectively were defined as the I/O Data Base which comprise a distributed data base among 
all controllers. System Control software updates the required data structures each system 
minor cycle (100ms for ASCLSS). These data structures are the tables which drive the System 
Control software in each controller. 

The innovative layered software architecture allows the subsystem or process developer to 
retain the controls responsibility and accountability, and in addition, achieves a consistent, 
common approach to operating system and communication system software. 

The software design and development responsibilities for the ASCLSS program are shown 
in Figure 3-7 and listed below: 

• Honeywell Design and Test Responsibility 

a. Automation and control software services programmed in PASCAL and in 1750 A 
assembly language. 

- Operating systems services or scheduling 

- Communications services 

- Hardware I/O 

- Data base management 

- Controller redundancy management. 
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Figure 3-7. ASCLSS Software Partitioning 


b. Man-machine interface displays and control operations programmed in PASCAL. 

- Keyboard commands from operator 

- Display formats/sequences 

- ARG status, warnings, alarms, event logs, sensor/actuator set points. 

• Life Systems, Inc. Design and Test Responsibility 

a. ARG system control level and ARG subsystem process control or application software 
programmed in PASCAL. 

- Control algorithms 

- Startup/shutdown procedures 

- Mode transition sequences 

- ARG system control policies/procedures 

- System level fault detection 

- Monitor functions. 

b. ARG process simulations programmed in PASCAL. 
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3.3.3 Application of ARG Process Simulators 

The ASCLSS demonstrator architecture shown in Figure 3-1 illustrates the use of simulators 
as a replacement for the subsystem process hardware during development. The three ARG 
simulators (hardware and software) were developed by Life Systems, Inc. The simulators 
(implemented with commercially available personal computers) can be used to develop and 
checkout the process controller software before the flight hardware is available or they can 
be used to demonstrate contingencies or failures with greater flexibility than real hardware. 
In the latter example, the simulators can play an important role in testing or verifying the 
automation and control hardware and software including redundancy management aspects 
and artificial intelligence or expert systems (AI/ES) software without requiring the process 
hardware to be present. 

Each of the three ARG process simulators respond to actuator output commands from their 
respective basic controllers and duplicate the response of the actual ARG process hardware 
to the same commands. This is accomplished by a dynamic computer model residing in each 
simulator. The ARG subsystems are the CO 2 Electrochemical Depolarized Concentrator 
(EDC), the Sabatier CO 2 Reduction (S-CRS) and the Static Feed Electrolyzer (SFE) for O 2 
generation. Each simulator replaces its corresponding mechanical subsystem hardware pack- 
age and provides a useful tool in the demonstration of the basic controller concept. Each 
simulator provides a friendly human interface that enables the user to monitor the simulation 
during system operation and to choose from a variety of operational scenarios. 

The ARG simulations were developed and targeted on IBM PCs using PASCAL and RTOS 
(Real-Time Operating System). Each simulator was connected to a controller over an RS232/ 
422 serial bus and to the other two simulators over an RS232 LAN. The RS232 serial bus 
carried the messages associated with sensor and actuator data and the RS232 LAN carried 
environmental and subsystem fluid flow interface data. Subsystem interface data is data 
relating to fluids, gasses, and temperatures shared where the subsystems physically interface 
to each other. 

The ARG simulators also simulated an on-orbit crew loading in the module and the module 
environment in addition to the subsystem simulation. This was required since the ARC. a ’so 
interfaces and its performance is affected by the local atmospheric environment and the 
environment is driven by crew loading. 

The following list describes the general features of each of the ASCLSS ARG simulators: 

1. Retrieves commands (actuator signals) from the basic controller and calculates via 
software routines a new state of the subsystem. The simulator will subsequently send 
back to the basic controller information (sensor values) describing the new state of the 
process. It also provides process data to basic controller on command. 

2. Displays a subsystem schematic continuously updated with new sensor, actuator, flow, 
valve setting, and fluid level data (figure 3-8). 

3. Displays sensor/actuator status listings in tabular form in display windows. Prints out 
display content on operator request. 

4. Displays the ARG subsystem’s effect on the environment and the interfaces with other 
subsystems. 

5. Provides an option of running the simulation in scaled time (real-time, faster that real- 
time or slower than real-time). 
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Figure 3-8. Simulator Schematic Screen 


6. Provides the capability of conducting the simulation as a steady-state process with 
operator keyboard input or a dynamic process with communication (i.e., actuator signals) 
with the basic controller. 

7. Allows the user to pause the simulation, store the data base on a floppy diskette, load 
an existing data base or restart the paused simulation. 

8. Provides an option of operating the simulator in a stand-alone subsystem simulation 
mode or connected to other subsystem simulators to form an ARG network. 

9. Provides for each subsystem up to ten preprogrammed, common failure events that the 
user can select and test the automation system response. 

The primary benefit of utilizing the ARG process simulators is to checkout controllers before 
actual process mechanical hardware is available. Another benefit of the simulator is the 
ability to introduce hardware failures to demonstrate the controller’s capability to handle a 
range of failures. Mechanical hardware would not aid such a demonstration without risking 
damage to the process equipment by operating at out-of-range conditions. The simulator can 
also be instrumental in the development of improvements to existing designs (rapid proto- 
typing). By conducting feasibility studies, one can determine whether a new control or change 
to an existing control would be useful. Simulators can also provide a means to conduct 
parametric studies to determine interrelationships between system process variables. All of 
these benefits reduce subsystem development costs. More detailed information on the ARG 
simulators and the ARG application software development are contained in the Life Systems, 
Inc. Final Report, TR-569-30, May, 1986. 
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3.3.4 Generic Man-Machine Interface (MMI) 


The success of the permanently manned Space Station will depend heavily on man’s dem- 
onstrated productivity in space. Through the crew’s ability to be productive and their flex- 
ibility to adjust to mission contingencies, man will establish his value in future Space Station 
operations. 

Currently, manned space operations with the STS (Shuttle) depend heavily on the crew to 
control the complex subsystems and on-orbit activities. Though most Shuttle orbiter sub- 
systems are to a large extent automated, the basic design philosophy demands a flight or 
ground crew control input/monitor function. The future Space Station design will exhibit 
high levels of automation including automated redundancy management. To meet these new 
challenges, the on-orbit crew role will transition from a “controller” to a “manager” of vast 
quantities of information. 

Space Station systems studies indicate that the design of a system’s crew interface should 
be integral to the design of the automation controller of that system. Experience has shown 
time and again that the MMI must be designed to reflect the levels of automation in the 
control system. At one time, for example, control systems were largely manual and the MMI 
reflected this automation approach by the provision of numerous dedicated controls for process 
mode selection and process control. Similarly, for virtually every control (or set of functionally 
related controls) there was a dedicated display for monitoring the process(es) under control. 

The ASCLSS program emphasizes an automation technique featuring a high level of sub- 
system autonomy or system “self-control” (e.g., mode selection, system initialization and 
startup, and mode transitioning) and “self-monitoring”. However, the MMI must be designed 
so that the crew member never is in a position of not being able to override the automatic 
control features of any Space Station subsystem. 

The Space Station workstation or MMI will offer an operator a single console or workstation 
to monitor any of the many complex systems. The MMI can be extremely effective when the 
concepts of supervisory control, standardization, responsiveness and a forgiving interface are 
well thought out early in the system design phase. These issues ar« discussed below. 

Supervisory Control. Provide the human operator with an integrated system representation 
at all times. This is especially important in the event of a critical system failure, when under 
high stress and mental workload, human operators may tend to narrow their attention to 
one or two displays and controls. 

Standardization. Standardize display screen formats, display information coding techniques, 
control input formats and interaction procedures. 

Responsiveness. Provide the human operator with the ability to move rapidly and easily 
between system, subsystem and component details. Minimize system response time and pro- 
vide effective feedback for all user inputs. Never leave the user with a blank screen. 

Forgiving Interface. Use software safeguards to prevent the user from making critical errors. 
Provides advise if improper command or unsafe request is made by the operator. 

3.3.5 ASCLSS MMI Operational Requirements 

The objective of the ARG MMI is to promote crew confidence in both the system performance 
and in the controls approach. The human operator is able to monitor system status and 
change system modes, sensor and actuator settings and responds to alarms or warnings. 
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Status Monitoring. The ARG operator can monitor the status and mode of all subsystems. 
Subsystem status will be OK, WARNING, or ALARM. Subsystem modes will be DEGRADED, 
SHUTDOWN, STANDBY, NORMAL, PURGE, or UNKNOWN (communication failure). If 
a subsystem process is in transition, text describing the transition is shown in the mode field 
(e.g., Normal -> Standby). The alphanumeric characters used are of normal polarity (white 
on black), without serifs and not slanted or rotated. Mixed upper and lower case is used to 
improve readability and uppercase alone is used in titles to focus attention. Figures 3-9 and 
3-10 provide examples of the MMI displays for the ARG system and the CO 2 reduction process 
schematic. 

Mode Transition Enabling. The ARG operator can enable system mode transitions. Required 
display information includes current mode and allowable mode transitions. Software safe- 
guards preclude illegal transitions (and an error message will be displayed to the operator) 
or require the operator to provide additional inputs to confirm the transition. 

Sensor Value Checking and Setpoint Changes. The ARG operator can access current sub- 
system sensor readings and setpoint values and modify the high and low alarm setpoints, 
the high and low warning setpoints and the high and low setpoint enables. Sensors that 
control an actuator also have high and low control setpoints that the ARG operator can 
modify. Setpoints may have any real value within a given range or the value NONE and 
setpoint enables will be ON or OFF. Software safeguards verify a high alarm value is greater 
than a high warning value which in turn is greater than a low warning value, etc. An error 
message notifies the operator of an illegal entry. A two-step control input process requires 
the operator to verify setting changes before implementation. 

Actuator Setting Changes. The ARG operator has the ability to override and change subsystem 
actuator settings. Required display information includes current actuator setting and setting 
options. Depending on the actuator, setting options will be OPEN, CLOSED, ON, OFF, AUTO 
(no override), or a have a value. Again, a two-step control input process requires the operator 
to verify setting changes before implementation. 

Software safeguards will either preclude illegal (e.g. unsafe) configurations and an error 
message will be displayed to the operator, cr r^quire the operator to provide additional control 
inputs to confirm such a setting. Subsystem status summary displays note overridden ac- 
tuators. 

Responding to Alarms. The ARG operator receives visual and auditory notification of sub- 
system alarm status, and visual notification of subsystem warning status. The ARG operator 
is required to acknowledge each alarm but not each warning. Alarm and warning status 
displays do not interfere with operator actions. An event log of subsystem events, alarms 
and warnings is available to the operator for display and printout. 

In summary, the ASCLSS MMI was designed to move the on-orbit crew from an “operator” 
to a “supervisor” of multiple automated subsystems. The ASCLSS system automated the 
ARG and thus freed up the crew to perform user operations. However, the MMI allowed the 
crew to respond to a warning or alarm, exercise override command authority, and investigate 
system malfunctions, if required. 
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Figure 3-10. Representative MMI Schematics Required for 
Space Station Automated Subsystem Control 
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Section 4 


FABRICATION (TASK 3.1.3) 


4.1 TASK OBJECTIVES 

This task included the purchase, fabrication, assembly, and unit testing of the generic au- 
tomation and control hardware elements, with special emphasis on the subsystem simulators. 
The automation system software including application software, operating system software, 
and simulator software was to be written, debugged, and unit tested under this task. 


4.2 TASK APPROACH AND RESULTS 

The ASCLSS real-time controllers were fabricated with Mil-Spec electronics wherever pos- 
sible. For example, the MIL-STD-1750A CPU cards and MIL-STD-1553B communication 
cards were provided from a Honeywell military helicopter program. All controller avionics 
boxes were exactly the same, allowing efficient build and spares strategies. All controller 
cards were individually tested in the controllers using test software and the target 1750 A 
CPU. 

In order to successfully develop the multiple ASCLSS software elements in three different 
company environments and effectively control and integrate them in the ASCLSS real-time 
controls system, a structured software development approach had to be employed. The fol- 
lowing software specification and control documents were created and closely managed (Fig- 
ure 4-1): 

• ASCLSS Software Specification (Reference 8). The ASCLSS Software Specification de- 
fined the functional requirements and top level design approach for the Application 
software in the system and subsystem controllers, the system control software, the op- 
erating system software, and the ARG simulator software. 

• Pascal Software Development Guidelines (Reference 9) . The Pascal Software Development 
Guidelines defined the PASCAL language statement extensions (for the IBM PC) which 
could not be implemented in the controller and defined the Pascal system shell for the 
controller. This prevented use of statements not handled by the 1750 A compiler. 

• I/O Data Base Control Document (Reference 11). The I/O Data Base Control Document 
provided Life Systems with the definition of all of the data structures in the controllers. 
This was a living control document containing data sheets which Life Systems completed 
as they defined the content of the data structures. 

• Software Interface Control Document (Reference 12). This document defined all the mes- 
sages and formats that were to be communicated between the MMI, system controller, 
basic controllers, and the simulators. 

• Software Development and Integration Plan (Reference 10). This document described the 
software environments at each facility and the test and verification requirements and 
the software development and integration plan for the entire ASCLSS program. 
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Figure 4-1. Structured Software Development Program 


The generic layered software approach developed by Honeywell allowed for parallel software 
development of all software at the three development facilities. This was accomplished by 
the development of system control software in the generic controllers which provided virtual 
communications and I/O to the application software and a symbolic distributed data base for 
the MMI. 

Since the application software developed at Life Systems, Inc. had no knowledge of the 
Instruction Set Architecture (ISA), the controller hierarchy, communications protocols, I/O 
interfaces, or the target operating system, the application software could be developed and 
tested on any software development system which supported a Pascal compiler. By avoiding 
extensions to the Pascal language standard and following the documents developed by Honey- 
well SSAvD, the application software could be statically and dynamically tested in the LSI 
software development system. 

Since the system control software was isolated from the application software by a data in- 
terface and was table-driven (i.e., independent of any application), it was developed in iso- 
lation from the application. This provides confidence that the generic software developed on 
the ASCLSS program will work for future applications in different subsystems. 

The MMI software issued commands to and requested data from the system controller on a 
symbolic basis. The MMI was able to request data from any controller and issue commands 
to any controller with no knowledge of the controller hierarchy or the specific data location. 
By following the Interface Control Document and the I/O Data Base Control Document, the 
development and testing of the MMI could and did proceed in parallel with all the software 
developed on the project. 
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The living software control documents, application source code, annotated software listings, 
program action registers, and monthly status reports were exchanged between the three 
geographically remote companies. This was accomplished by establishing a telecommuni- 
cations network between Honeywell SSAvD, Honeywell SRC, Life Systems, and NASA JSC 
(Figure 4-2). By using modems, telephone lines, personal computers, and minicomputers, all 
documents and software were exchanged electronically providing instant feedback on 
changes, problems, and solutions. The effective application of telecommunications to ex- 
change information and software was an essential component for the timely success of the 
ASCLSS program. 

Communications between the ASCLSS participants was maintained through an early, TMIS- 
like network. LSI (the process experts) were able to develop both the control process software 
and the simulator software in their own facility on their development system (IBM PC), 
resulting in cost and time savings by using a development environment that LSI was accustom 
to. Updated versions of the ASCLSS application software were available to both Honeywell 
and NASA in a timely fashion through the use of bulletin boards and telecommunications. 
It is believed that this application of modern telecommunications to support software de- 
velopment and program technical management saved the ASCLSS program significant cost 
and greatly reduced program risk. Equally important, the ASCLSS layered software archi- 
tecture and the tight control of the software interfaces also contributed to the parallel and 
independent development of the major software efforts on the program. 



Figure 4-2. Telecommunications Were Key to ASCLSS Development 
and Integration Success 
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Figure 4-3 represents conceptually the ASCLSS application task or program and the data 
and command structures and information flow between the MMI, the system controller, the 
basic controllers, and the real time process simulators. Note that commands and data are 
exchanged through table driven data structures established by the I/O database. 

The ACLSS automation and control system memory budget or memory map is shown in 
Figure 4-4. The real-time operating system is the same in all controllers and occupies 3600, 
16-bit instruction words in the controller’s E^PROM. Note that the ASCLSS program software 
runs out of E^PROM (nonvolatile memory) while the operational data structures run in 
RAM. The expansion factor experienced in converting Pascal lines of code to words in the 
1750 A averaged approximately five. The memory budget in Figure 4-4 indicates that the 
ASCLSS software program in each controller occupies only about 25-30% of the 64K words 
capacity of the E^PROM and the data structures consume only 12-20% of the available RAM. 

The 1750A microprocessor in each controller also has unused capacity for additional tasks. 
Diagnostic measurements made for the controllers indicate in Figure 4-5 that only about 
60% of the 100 millisecond minor cycle is used by the ASCLSS controllers to complete the 
normal automation tasks during each cycle. 

Thus, significant memory resources and CPU capacity exists to perform additional tasks like 
redundancy management, process and controller health monitoring, and embedded artificial 
intelligence/expert systems (AI/ES) in real-time control. 

And finally, the ASCLSS program represents a mini-model of how the Space Station auto- 
mation and control development will be accomplished through coordinated efforts between 
NASA, the DMS subcontractor, and multiple process and hardware subsystem developers. 
Many of the important ASCLSS lessons learned, which are summarized in Section 7 and 
detailed in Appendix B, will have direct applicability to the future Space Station automation 
and controls development. 

Because of its relevancy to the future Space Station, and at NASA’s request, an evaluation 
was conducted to assess the size and cost of the significant software development completed 
on the /. 3CLSS program. Table 4-1 summarizes the results of this software analysis. In this 
table, the term “SLOC” stands for Single Line Of Code written in high order language. The 
following points can be made: 

• Honeywell software efforts included: (1) systems engineering, (2) development of the 
system control software, operating system, and test software, and (3) overall system 
software integration. 

• The cost of systems and integration responsibility adds significantly to the software 
program software development cost (35%). 

• Application software provided by LSI was ported from existing ARG process control 
applications to Pascal and, thus, LSI’s rate of development in SLOCS/day are higher 
and Cost/SLOC are somewhat lower than Honeywells. 

• These figures of merit for software development are significantly lower than currently 
being used for planning purposes on Space Station. However, the ASCLSS software is 
development software, not flight software. Also, redundancy management functions are 
not implemented and the software was written in Pascal instead of ADA. These addi- 
tional features are expected to add significantly to the Space Station software devel- 
opment costs. 


4-4 



MM 
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4-1 . ASCLSS Software Development 


Honeywell 




Life Systems, Inc. 


Operating System (Assy)/Test SW 

9,600 SLOCS 

Application Software 

10,700 SLOCS 



(equiv) 



System Control SW (Pascal) 

3,300 SLOCS 

Simulator Software 

10,900 SLOCS 


Total 

12,900 SLOCS 

Total 

21,600 SLOCS 

Labor 




Labor 


Systems 


200 

Man-Days 

Application Development 

300 Man-Days 

Development 


900 

Man-Days 

Simulator Development 

350 Man-Days 

Integration 


260 

Man-Days 




Total 

1,360 

Man-Days 

Total (Design, Devel, Test) 

650 Man-Days 

Software 

Systems & 


Systems & SW Application 

Simulation 

Development 

Sw Devel 


Dev & Integ Development 

Development 

$36/SLOC 

$46/SLOC 


$56/SLOC $18/SLOC 

$12/SLOC 

14 SLOCS/Day 

12 SLOCS/Day 

9.5 SLOCS/Day 18 SLOCS/Day 

31 SLOCS/Day 

Comments: 




Key: 


• Not flight software 




• Single line of Code (SLOC) in high order 

• Redundancy management not inclulded 


language 


• Software is not ADA 






• LSI application software translated to Pascal 
from existing ARG software 
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4.3 APPROACH TO QUALITY ASSURANCE, RELIABILITY AND SAFETY 


Though ASCLSS represents a technology development program, the implementation of the 
demonstration system design, development, and test was performed at a Honeywell division 
whose major business is man-rated, space qualified avionics hardware. 

Within constraints of cost and the ASCLSS program development schedule, many features 
were incorporated and fabrication policies and procedures were followed which relate to 
quality assurance, reliability, and safety in the ASCLSS demonstration system. 

A summary of the Q/A, reliability, and safety efforts performed on the ASCLSS program are 
listed below: 

• Quality Assurance: 

1. The ASCLSS common controller hardware included 1750A CPU and 1553B cards 
from a military flight program (Mil-Spec parts and assembly). 

2. The basic controller chassis was redesigned to a small, compact configuration 
(nearer to flight size). 

3. The cooling fans in the controllers were replaced with high speed fans exhibiting 
double the flow initially designed in. 

4. An E^PROM protection circuit and switch are provided to prevent inadvertent 
program erasures. 

5. All hardware assembly was performed by highly skilled aerospace engineers and 
technicians using standard practices. 

6. The controller cards were “burned-in” tested at least 300 hours prior to delivery. 

7. High quality electronic parts were used wherever possible. 

8. Higher flow rate fans were also installed on the IBM PCs to increase thermal 
margins. 

9. A step-by-step sequence of tests from card, box, and system was employed for both 
hardware and software. 

• Reliability 

1. Added thermal margin and protection were provided by larger fans in the ASCLSS 
controllers and PCs which will improve electronic parts reliability. 

2. Differential driver cards were added to each IBM PC to increase communications 
reliability and performance. 

3. E^PROM memory protection circuit was provided to maintain controller software 
integrity. 

4. The controller CPU and 1553B cards are military flight quality boards. 

5. The controller chassis, backplane, connectors, RS232 card, and memory card are 
fabricated from high quality commercial parts. 

6. The ASCLSS demonstration system does not preclude the efficient application of a 
more detailed reliability program in the future. 
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• Safety 


1. Detailed system assembly instructions were written to provide safe and effective 
assembly of the ASCLSS hardware. 

2. Current/circuit protection was provided by fusing at the controller rear panel and 
in the power supply. 

3. The controller chassis was designed to protect the user from electric shock with a 
box cover and fan guards were included for all controller and PC fans. 

4. Antistatic mats for floor and bench were employed for all assembly and repair 
operations. Cards were stored and shipped in antistatic envelopes. 
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Section 5 


TEST OF THE AUTOMATION APPROACH (TASK 3.1.4) 


5.1 TASK OBJECTIVE 

Under this task, the hardware and software elements of the generic automation approach 
and subsystem simulators were to be thoroughly integrated and tested. The testing program 
objectives and plan were to test all elements for proper operation, and demonstrate the of 
generic aspects of the automation and control technique to the air revitalization group using 
the subsystem simulator! s). The completion of the task would be an acceptance test program 
designed to demonstrate these dual objectives. 


5.2 TASK APPROACH 

As discussed previously, the layered software architecture and division of development re- 
sponsibilities between the ASCLSS contractors allowed a parallel and independent devel- 
opment and test plan to take place. The definitive software control documents and the use 
of telecommunications to coordinate changes and status of all activities greatly facilitated 
the parallel development approach. 

The sequence of test and integration steps for the ASCLSS automation and control system 
are shown in Figure 5-1. At Honeywell, the operating system and I/O data base and system 
control software were tested in the system and basic controllers using test software that 
simulated ARG application software. Once a system controller and basic controller were 
tested successfully, the MMI and ARG simulator were added and tested using test software. 
Following a successful ASCLSS “single string” test, the remaining two strings or channels 
of the system were added. A full-up system test at Honeywell usi"g strictly test software 
was conducted which included a systems communications “stress test”. During a two hour 
test of the entire system, 1.36 x 10® messages, or 5.4 trillion bits of data, were exchanged 
successfully between the controllers on the 1553B busing network without a single error! 

In parallel with the Honeywell SSAvD developments and tests, LSI developed their ARG 
application software (ARG system management and SFE/EDC/S-CRS process control) and 
SFE/EDC/S-CRS simulator software. These software packages were developed and tested 
both statically and dynamically at LSI on IBM PCs. At the same time, the MMI software 
was also being developed at Honeywell SRC (Minneapolis) using test software to simulate 
the ASCLSS system interface and data flow. 

Thus, as Figure 5-1 indicates, all software was tested at the three separate development sites 
prior to final integration at Honeywell SSAvD in Clearwater. This resulted in a uniquely 
successful integration of all ASCLSS software in less than a week. This process essentially 
took place by removing the test software and linking in the ARG application software as 
illustrated in Figure 5-2. Following integration, software problems that arose were efficiently 
and effectively resolved by making software changes and using the telecommunications sys- 
tem discussed previously. 


5-1 



787-079 


SYSTEM CONTROLLER 


CARD TESTS 


BUILD O.S. 


BASIC CONTROLLER 


BUILD O.S. & I/O D.B. 

i 


TEST SYNC" 


BUILD O.S. & SYS CONTROL 


BUILD TEST APPLICATION 


X 


BUILD O.S. & I/O D.B. 

X 


BUILD O.S. & SYS CONTROL 


TEST 1553 COMM 


VERIFY I/O D.B. 

X 


X 


BUILD TEST APPLICATION 

X 


VERIFY I/O D.B. 

X 


BUILD TEST MMi~| — » | TEST MMI COMM | » |TEST SINGLE STRING^ 1 TESTSIM COMM 


V 


X 


BUILD TEST SIM 


MMI 


TEST MMI & SYS CONTROL 

— > FULL SYSTEM 

K-T 

TEST SIM & SYS CONTROL 1 

* . 1 ^ 

TEST MMI & APPLICATION 

— »j SINGLE STRING 


TEST SIM & APPLICATION 


BUILD APPLICATION 


X 


SIM 


TWO STRINGS 

X 


BUILD APPLICATION 


FULL ARG SYSTEM 

I 


ASCLSS ATP 


Figure 5 - 2 . ASCLSS Integration Plan 


SYSTEM CONTROLLER 



TEST SOFTWARE 


TEST SOFTWARE 


TEST SOFTWARE 


iSFE PROCESS CNTL 
APPLICATION 
SOFTWARE 


BASIC CONTROLLER 


|EDC PROCESS CNTL| 
APPLICATION 
SOFTWARE 


BASIC CONTROLLER 


ISCRS PROCESS CNTLj 
APPLICATION 
SOFTWARE 






llSfiiillP 

I/O DATA BASE 


I/O DATA BASE 


I/O DATA BASE 

SYSTEM CONTROL 


SYSTEM CONTROL 


SYSTEM CONTROL 

OPERATING SYSTEM 


OPERATING SYSTEM 


OPERATING SYSTEM 


BASIC CONTROLLER 


Figure 5-2. Application Software Integration Strategy 


5-2 








A detailed acceptance test plan and procedure (reference 17) was developed which included 
a logical sequence of tests from card testing to a complete ASCLSS system test that dem- 
onstrated the critical features of the automation and control approach. Table 5-1 summarizes 
the important tests included in the ASCLSS acceptance test program. 

Table 5-1. ASCLSS Acceptance Test Sequence 

1.0 Automation Hardware Tests (in each controller) 

1.1 Memory Test 

1.2 CPU Self-Test/Timer Tests 

1.3 MIL-STD-1553B Test 

1.4 Operating System/RS232 Communications Test 

2.0 Automation System Tests (Test Software Driven) 

2.1 I/O Data Base Test 

2.2 Primary System Bus (MS 1553B) Failure 

2.3 Secondary System Bus (MS 1553B) Failure 

2.4 System Bus Channel Failure Test 

2.5 Simulator Bus (RS232) Failure 

2.6 Controller Hardware Failure Test 

3.0 ARG System Tests 

3.1 Power Up, Initialization Sequence Test 

3.2 Mode Transition Tests 

3.3 Controller Tests 

3.4 MMI Monitoring and Control Tests 
Sensor Failure Tests 

Actuator Failure Tests 
Process Autonomy Tests 

3.5 Controller Failure Tests 

System Bus (MS 15533' 'Failure Test 
System Controller RS232 Failure Test 

4.0 Two-Hour System Test in Normal Mode 
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Section 6 


DELIVERY TO JOHNSON SPACE CENTER (JSC) (TASK 3.1.5) 


6.1 TASK OBJECTIVE 

At the conclusion of the integration and test program, the automation equipment was shipped 
to NASA JSC, setup and demonstrated. Program documentation was delivered within one 
month of system hardware delivery. 


6.2 TASK APPROACH 

The ASCLSS system was successfully acceptance tested at NASA JSC in July of 1986. Fol- 
lowing a brief period of system demonstration at NASA the system was returned to Honeywell 
to incorporate several enhancements that were to improve the demonstration features of the 
ASCLSS automation and control system: 

• Incorporated system and individual ARG process sequence steps to be displayed on the 
MMI during system mode transitions 

• Provided capability for hardcopy printout of MMI event log 

• Incorporated a speed up mode in the ARG simulators that allowed the ASCLSS system 
to move through its transitions in significantly shorter times (roughly a factor of 10 
faster than real-time representation). 

These enhancements were completed in March of 1987. Following a demonstration of the 
ASCLSS system at NASA Headquarters on April 4, the system was again delivered and 
acceptance tested at NASA JSC. Figure 6-1 presents a photo of the delivered ASCLSS dem- 
onstration system 
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Section 7 

SIGNIFICANT PROGRAM LESSONS LEARNED 


The true legacy of the ASCLSS development program are the many and significant lessons 
learned. A list of 50 of these lessons learned are included as Appendix B. Several of the more 
important ones are listed below: 

• The ASCLSS program demonstrates a control hierarchy which places maximum control 
authority at the lowest controller level. This controls hierarchy optimizes process and 
system autonomy and reduces subsystem interactions during integration. Maximum 
authority at the lowest controller level also provides an excellent vehicle for demon- 
strating distributed artificial intelligence/expert systems (AI/ES) which is discussed in 
Section 8. 

• In the ASCLSS approach, the automation and control authority, philosophy, and im- 
plementation remains the responsibility of the subsystem developer. “The application 
expert is accountable.” 

• The program demonstrated the effectiveness in using modern telecommunications in 
software development and transmission, data exchange, documentation control, and soft- 
ware configuration management. This is an early “proof of concept” of the Space Station 
Technical, Management, and Information System (TMIS). 

• The emphasis on standards such as: MIL-STD-1750A, MIL-STD-1553B, RS232, Pascal, 
and standard development systems such as IBM PCs and VAX mainframes, fostered 
portability, and use of readily available development tools for both hardware and soft- 
ware. 

• The benefits of a common family of controller cards was demonstrated during system 
development where cards, and even whole controllers, were swapped to isolate hardware 
problems and to maintain development schedules. Also, one design fix applies to all 
common elements. An added benefit of a common card family is that one set of cards 
currently maintained at Honeywell serves as spares for nine ASCLSS controller units 
in the field. 

• The user-friendly MMI effectively supports an unknowledgeable user or operator. The 
air revitalization group system and individual ARG processes are easily monitored for 
operational status or wamings/alarms. The operation of the ASCLSS system is automatic 
and places the user in full supervisory control. 

• The subsystem simulators meet the testing requirements for real-time control appli- 
cations. The simulators can be programmed for failures, alarms, and rare system con- 
figurations which will exercise automation and control system logic with no risk to the 
process hardware or when early in the program development cycle when process hard- 
ware may not be available. The simulators will also be effective in test and validation 
of future development of embedded AI/ES functions. 
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• The software architecture features a distributed data base which provides for growth in 
system capability and accommodates future implementation of embedded AI/ES func- 
tions. 

• The ASCLSS layered software approach allows operational software to be application 
independent and the application software to be controller and microprocessor independ- 
ent (generic applicability and high portability). The layered approach facilitated the 
parallel development and independent software testing and resulted in straightforward 
and efficient software and hardware integration. 

Many of the important automation features pioneered and demonstrated in the ASCLSS 
program are providing direct payoff and benefit to NASA. Table 7-1 lists several ASCLSS 
features that are being planned or carried into the Space Station program. 


Table 7-1. ASCLSS Program Features 

ASCLSS Comparable Space 

Automation Features Station Features 


• Strong hardware commonality 


• Distributed controls hierarchy 


• Layered software with modularity and significant 
commonality 


• Distributed control with control authority pushed to 
lowest level 

• Effective use of process or subsystem simulators 


• Use of telecommunications in program management 
and software development 

• Crew placed in supervisory control of automated sys- 
tems 


• DMS common elements implemented across subsys- 
tems (NIU, SDP, EDP, MDM, etc.) 


• Similar three tiered control levels, established by 
OMS, SDP, and MDM 

• Common distributed operating system (DOS) pro- 
vided by DMS. Seven layered, OS1/ISO software ar- 
chitecture planned in NIU with common Network 
Operating System (NOS) 

• Not currently planned. Presently all application soft- 
ware resides in SDPs 

• Planned TAVERNS concept will provide this test ca- 
pability 

• Planned TMIS and SSE will provide these capabili- 
ties 

• Space Station OMS and MPAC will establish super- 
visory control role for on-orbit crew 


ASCLSS HAS PIONEERED AND DEMONSTRATED 
MANY SPACE STATION CONCEPTS 
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Section 8 


RECOMMENDATIONS FOR ADDITIONAL AREAS OF INVESTIGATION 


The ASCLSS program represents a significant first step in defining, developing, and dem- 
onstrating an automation and controls approach for the Space Station. However, there are 
many additional studies, development tasks, and technology demonstrations that can be 
performed that will expand the ASCLSS lessons learned and exploit the existence of the 
ASCLSS system as an early automation and control test bed. Some of these areas recom- 
mended for additional investigation are listed below: 

1. Develop an input/output I/O interface for one or more of the ASCLSS basic controllers, 
integrate the ARG process hardware to the ASCLSS system, and control the process 
with the ASCLSS system. This will complete the proof of concept to use real-time sim- 
ulators in place of process hardware to develop and test automation and control systems. 

< 

2. Evaluate and test what level of fidelity is required for a real-time simulator to effectively 
represent process hardware. 

3. Develop and demonstrate ARG system fault detection, isolation and recovery and system 
redundancy management. 

4. Enhance the MMI by incorporating multiple display screens, adding windowing tech- 
niques, and incorporating animated graphics and touch screens. 

5. Port the ASCLSS software system from Pascal to the Space Station HOL, ADA. 

6. Develop and demonstrate a policy and approach to on-orbit maintenance repair and 
replacement of system hardware and software. Determine the viability of repair or 
replacement at the card level for on-orbit operations. Also, how do you change or repair 
software on-orbit? 

7. Host different Space Station applications (GN&C, thermal, power, etc.) in the ASCLSS 
system. Consider hosting multiple and different applications in the ASCLSS system so 
as to emulate a shared SDP. 

8. And finally, develop and demonstrate the inter-relationship and an approach to incor- 
porating artificial intelligence and expert (AI/ES) systems embedded in a real-time 
controller. 

These investigations are relatively straightforward by using the ASCLSS system as an ex- 
isting automation and control test bed. 
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Section 9 


CONCLUSIONS 


The Automated Subsystem Control for Life Support System (ASCLSS) program has suc- 
cessfully developed and demonstrated a generic approach to the automation and control of 
Space Station subsystems. The automation system features a hierarchical and distributed 
real-time control architecture which places maximum controls authority at the lowest or 
process control level which enhances system autonomy. The ASCLSS demonstration system 
pioneered many automation and control concepts currently being considered in the Space 
Station data management system (DMS): 

• Heavy emphasis is placed on controls hardware and software commonality implemented 
in accepted standards. 

• An innovative layered software architecture was developed which accommodated in- 
dependent and parallel software development and relatively straightforward hardware 
and software integration. 

• The automation system architecture retains the controls responsibility and accounta- 
bility with the subsystem or process developer. 

• The approach demonstrates successfully the application of real-time process or subsystem 
simulators to support development and validation of automation and control hardware 
and software. This is an early “proof of concept” of the NASA TAVERNS (Test and 
Verification Environment of Networked Systems) V&V approach. 

• The ASCLSS system completely automates a Space Station subsystem (air revitalization 
group of the ECLSS) which moves the crew/operator into a role of supervisory control 
authority. 

The ASCLSS program developed over 50 lessons learned which will aid future Space Station 
developers in the area of automation and controls. And finally, the ASCLSS demonstration 
system represents an early test bed which will support additional technology studies and 
development activities including evaluation of controls requirements, application of ADA 
software to real-time control, and development and demonstration of embedded artificial 
intelligence and expert (AI/ES) systems in a distributed automation and controls system. 
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suits in longer development 
times when interfaces are being 
developed. Any problems en- 
countered must be resolved 
without factory assistance. 
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without disturbing the process 
display. As such as possible, 
the process schematic was the 
primary display. 
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